Taskboards - Access Requests

The Access Requests page (System Configuration > Taskboards > Access Requests) allows you to define Permission Assist settings that affect the Change Management taskboard. You can also define corrective control policies for access requests. Settings in this area affect all access requests in all reviews and personnel events.

Settings Tab

This area allows you to determine which options are available within the Remediation/Change Management Taskboard.

Changing these options may affect access requests that were initiated within a currently open review.

Friendly Reminder: When you've finished making changes, select the Save button. If you forget to save your changes before leaving this page, your changes will be lost.

Actions
Option	Description
View Risk Ratings	Allows you to determine whether reviewers are able to see the risk ratings assigned to each privilege. By default, this field is set to "Nobody" meaning risk ratings will not be displayed to anyone. To change this setting: Select View Risk Ratings and then select a different option (Everyone, Security, or Trusted). When permitted, risk ratings are shown on the far-left column and are indicated by their associated color (see example below). Red - Critical Orange - High Green - Moderate Blue - Low
Can Act on Own Access Requests	Allows you to determine whether reviewers are able to take action on access requests associated with their own privileges. By default, this field is set to "Everyone" meaning everyone will be able to take action on access requests associated with their own privileges. To change who can take action on requests relating to their own permissions: Select Can Act on Own Access Requests and then select a different option (Security, Trusted, or Nobody). Anyone who is restricted from reviewing their own permissions will see the approval restriction message displayed in the Review Buttons area of the Remediations/Change Management Taskboard (see picture below).
Always show a warning message even if the user can act	This option works in conjunction with the Can Approve Own Access Requests option. When this option is selected, anyone who is allowed to take action on access requests related to their own permissions will see the following warning message displayed in the Review Buttons area of the Remediations/Change Management Taskboard (see picture below). Selecting the I understand and wish to continue link at the bottom of this message allows the Provision Engineer to continue reviewing their own permissions and take action as needed.

Notifications
Option	Description
Send an email alert when an access request is created	Select this option if you want to enable automatic email notifications for the Provision Team. If selected, email notifications will be sent to the email address in the Default Access Request Email field when an access request is created. SMTP settings must be defined and enabled within the System Configuration > General Settings > Email tab in order for Permission Assist to send notifications. NOTE: Whether this option is selected or not, Permission Assist sends additional notifications to the appropriate person/people when an access request is approved, assigned, cancelled, completed, reopened, or resolved.
Default Access Request email	When the "Send an email alert when an access request is created" option is selected, use this field to specify the email address to which access request notifications are sent by default. This setting can be overridden at the application level (Manage > Applications > selected an application > Application Details page > Responsibilities tab > Remediation Alert Email)
Add an attachment detailing the access request	Select this option if you want to send detailed remediation information within the email notifications that get sent to Provision Engineers. This can be helpful if you're sending remediation notifications to an internal help desk team that doesn't have access to Permission Assist. When selected, this option will attach a detailed report of the remediation access request to the email notification (see sample below).

Workflow Tab

The Workflow tab allows you to define the corrective control policies for access requests. This is helpful when you have policies within your organization that require approval for changes in certain situations. These are just a few examples of when you may want to set up corrective control policies:

You want to ensure someone approves an access request before it gets sent to the Provision Team
You want to ensure someone verifies that access request changes were completed correctly
You want people within certain roles to pre-approve or verify access requests that a specified level of risk

Examples:
- You can set up a policy that requires an application owner to pre-approve any request related to a critical application
- You can set up a policy that requires a supervisor or department manager to approve requests that involve changes to critical permissions.

To create a corrective control, enter information into each field as described below:

Field

Description

Add [allowed watchers]

Determines the type of corrective control that's being created. Select this field to select one of the following options:

allowed watchers - this option is selected by default; when this option is selected, the policy will allow the selected role to view access requests
approver - when this option is selected, the policy will require the selected role to approve access requests before they are sent to the Provision Team
verifyer - when this option is selected, the policy will require the selected role to verify that the changes have been made properly before access requests are completed.

rule for [Security Team]

Determines which role is required by the corrective control policy. Select this field to pick the role.

Add Rule link

When the policy is defined as you would like it to be, select the Add Rule link to add the rule below, where it can be further defined.

Allowed Watchers

This area displays the "allowed watchers" rules/policies that have been added. Allowed watchers are able to view access requests, but they are not able to take action on requests unless they have another authority that would allow them to take action.

For each required control, enter information in the following fields as needed to define requirements:

Field	Description
Are [always]	This field allows you to determine whether the selected role is always able or conditionally able to view access requests. Select this field to select one of the following options: Always - By default, this field is set to "always", which means a person in this role is always able to view access requests. Conditionally - When this option is selected, a person in this role is able to view access requests if certain conditions are met. For example, if you want a Department Manager to be able to view access requests that involve to critical applications or privileges, select "conditionally" to further define the rule.
required if present	Allowed watchers are always considered "required if present" which means the rule will apply unless the selected role doesn't exist. For example, if you add a rule that says the Department Manager is an allowed watcher, the rule will only be enforced if a Department Manager has been defined.
when the [application]	This field appears when the "Are [always]" field is changed to "conditionally". By default, this field is set to "application" which means that the role is able to view access requests when an application has a certain priority level (defined in the "has a priority of" field) or higher. If this field is set to "privilege", the role is able to view access requests when a privilege has a certain priority level (defined in the "has a priority of" field) or higher.
has a priority of [None]	This field appears when the "Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the role is able to view access requests when the application or privilege has a priority/risk rating of "None" or higher. If you'd like the role to view applications or privileges of a specific priority or higher, select [None] and then select a priority level from the drop-down list.

Pre-Work Approval

This area displays the "pre-work approval" rules/policies that have been added. For each required control, enter information into the following fields as needed to define requirements:

Field	Description
At least [one]	NOTE: This option is not available when adding rules for Supervisors, Area Reviewers, Reporters, or any of the Defined Managers. When adding a new rule, this field is set to "one" by default which means that at least one person within this role is required. Some roles allow you to add two roles. To require two people within the role, select [one] and then select two from the drop-down list. Selecting "two" ensures that at least two people within the role will pre-approve each access request. For example, if you have 5 people within your Security Team, and you want to ensure that at least 2 of the 5 pre-approve access requests, set this field to "two".
Is/Are [always]	This field allows you to determine whether pre-approval is always required or conditionally required. Always - By default, this field is set to "always", which means a person in this role must approve access requests before the Provision Team member is able to take action. Conditionally - When this option is selected, a person in this role must pre-approve access requests, but only if certain conditions are met. For example, if you want a Department Manager to pre-approve any access requests that involve critical permissions, set this field to "conditionally" and then complete the other fields as needed. NOTE: Permissions must be risk rated before the review is started in order for this control to be applied properly.
Required	This field is set to "required" and is the only option available for Security Team members; however, other roles may be considered either required and/or required if present. Required - When this option is selected, a person in this role must pre-approve access requests as defined by the rule without any exceptions. For example, let's say a rule requires one Application Manager to always pre-approve access requests. If an access request is created for an application that doesn't have an application manager, one will need to be assigned in order for the request to be pre-approved. The pre-approval process cannot be skipped and other roles, such as the Security Team, cannot take the responsibility for pre-approal in place of an Application Manager. Required if present - When this option is selected, people within the role are only required to pre-approve requests if someone exists within the role. The policy will not be enforced if a person within the role does not exist.
When the [application]	This field appears when the "Is/Are [always]" field is changed to "conditionally". Select one of the following options: Application - by default, this field is set to "application" which means that a person within the role is required to pre-approve requests when the request relates to an application that has a certain priority level (defined in the "has a priority of" field) or higher. Privilege - If you'd like someone within the role to pre-approve requests only when a user has access to privileges of a certain priority, select [application] and then select privilege from the drop-down list.
has a priority of [None]	This field appears when the "Is/Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the members of this role are required to pre-approve requests when the application or privilege has a priority/risk rating of "None" or higher. If you'd like them to pre-approve applications or privileges of a specific priority, select [None] and then select the priority level from the drop-down list.

Post-Work Verification

This area displays the "post work verification" rules/policies that have been added. For each required control, enter information into the following fields as needed to define requirements:

Field	Description
At least [one]	NOTE: This option is not available when adding rules for Supervisors, Area Reviewers, Reporters, or any of the Defined Managers. When adding a new rule, this field is set to "one" by default which means that at least one person within this role is required. Some roles allow you to add two roles. To require two people within the role, select [one] and then select two from the drop-down list. Selecting "two" ensures that at least two people within the role will verify each access request after the Provision Team has completed their work. For example, if you have 3 people within your Security Team, and you want to ensure that at least 2 of the 3 verify each access request that involves critical permissions, set this field to "two".
Is/Are [always]	This field allows you to determine whether post-verification is always required or conditionally required. Always - By default, this field is set to "always", which means a person in this role must verify access requests after the Provision Team member completes their work. Conditionally - When this option is selected, a person in this role must verify access requests, but only if certain conditions are met. For example, if you want a Department Manager to verify any access requests that involve critical permissions, set this field to "conditionally" and then complete the other fields as needed. NOTE: Permissions must be risk rated before the review is started in order for this control to be applied properly.
Required	This field is set to "required" and is the only option available for Security Team members; however, other roles may be considered either required and/or required if present. Required - When this option is selected, a person in this role must verify access requests as defined by the rule without any exceptions. For example, let's say a rule requires a Department Manager to always verify access requests. If a Department Manager hasn't been assigned, one will need to be assigned in order for the request to be verified and completed. The verification process cannot be skipped and other roles, such as the Security Team, cannot take the responsibility for verification in place of the Department Manager. Required if present - When this option is selected, people within the role are only required to verify requests if someone exists within the role. The policy will not be enforced if a person within the role does not exist.
When the [application]	This field appears when the "Is/Are [always]" field is changed to "conditionally". Select one of the following options: Application - by default, this field is set to "application" which means that a person within the role is required to verify requests when the request relates to an application that has a certain priority level (defined in the "has a priority of" field) or higher. Privilege - If you'd like someone within the role to verify requests only when a user has access to privileges of a certain priority, select [application] and then pick the privilege option from the list.
has a priority of [None]	This field appears when the "Is/Are [always]" field is changed to "conditionally". By default, this field is set to "None" which means the members of this role are required to verify when the application or privilege has a priority/risk rating of "None" or higher. If you'd like them to verify applications or privileges of a specific priority, select [None] and pick the priority level from the list.